@jimjeffers - This is ready for your review. Please read the note to make sure you don't disagree with how this was implemented (follows current deployment map implementation).

Re:

In dash4, the map only shows the positions of the vehicle for the last 24 hours, ...

Just to clarify that this is actually user configurable in dash4: there's a maximum number of GPS positions to display setting as well as the length of the time window.

cc @heavyB @ksalamy

Thanks for putting this together. The feature direction is strong, but I think these 4 issues should be addressed before merge.

1) 24h fallback is mostly inactive because query enabled still requires deployment timestamps

Files:

• apps/lrauv-dash2/components/VehicleList.tsx
• apps/lrauv-dash2/components/VehiclePath.tsx

Right now we compute a default from (24h ago), but the queries are still disabled unless deployment timestamps exist. That means the fallback path often doesn’t execute.

Example adjustment (pattern):

const defaultFrom = useMemo(() => Date.now() - 24 * 60 * 60 * 1000, [])
const queryFrom = lastDeployment?.lastEvent ?? defaultFrom

const { data: vehiclePosition } = useVehiclePos(
  { vehicle: name, from: queryFrom },
  { enabled: !!name }
)

In VehiclePath, use the same queryFrom approach and avoid enabled that depends on lastDeployment?.startEvent?.unixTime.

Tradeoff:

• enabled: !!name may cause an extra request before deployment metadata resolves.
• Gating on deployment metadata avoids that extra fetch but delays or suppresses data in “missing metadata” cases.
• If the product requirement is “always show recent positions,” the immediate fallback is the better trade.

2) Emergency toast persistence doesn’t match the intent

File:

• apps/lrauv-dash2/lib/useRefreshPositions.tsx

Current logic sets timeout = 0 for emergencies but then uses duration: timeout || undefined, which converts 0 to undefined and falls back to default behavior.

Example adjustment:

const duration = hasEmergencies ? Infinity : REFRESH_TOAST_DURATION_MS

toast(message, {
  id: getRefreshToastId(vehicleName),
  position: 'bottom-left',
  duration,
  className: 'refresh-position-toast',
})

Tradeoff:

• Persistent emergency toasts improve visibility for critical events.
• They can clutter the UI if multiple vehicles alert.
• Good compromise: persistent + explicit dismiss, or long finite duration for emergencies.

3) refreshAll rethrows after showing error toast, which can surface unhandled promise rejections in click handlers

Files:

• apps/lrauv-dash2/lib/useRefreshPositions.tsx
• Call sites in map components (onRequestRefresh={refreshAll})

refreshAll handles UI error reporting already, then rethrows. Since it is used as a button click callback, this can produce noisy unhandled promise rejections.

Example adjustment A (UI-safe default):

catch (error) {
  logger.error('Error refreshing positions:', error)
  toast.error('Failed to refresh vehicle positions', { position: 'bottom-left' })
  return undefined
}

Example adjustment B (keep throw semantics but consume at callsite):

onRequestRefresh={() => {
  void refreshAll().catch(() => {})
}}

Tradeoff:

• No-throw behavior is cleaner for UI handlers.
• Throwing is useful if callers/tests need strict failure propagation.
• Best long-term API is often two functions: a UI-safe refreshAll and a strict refreshAllOrThrow.

4) Auto-refresh timing is coupled to a callback with unstable identity

File:

• apps/lrauv-dash2/lib/useRefreshPositions.tsx

The auto-refresh effect depends on refreshAll; if refreshAll is recreated frequently (due to non-memoized array/object inputs), timers reset and scheduling can drift/miss expected execution.

Example adjustment:

const refreshRef = useRef(refreshAll)
useEffect(() => {
  refreshRef.current = refreshAll
}, [refreshAll])

useEffect(() => {
  if (!autoRefreshMinutes || !lastRefreshed) return

  const nextAt = lastRefreshed.getTime() + autoRefreshMinutes * 60_000
  const delay = nextAt - Date.now()

  const run = () => {
    void refreshRef.current()
  }

  if (delay <= 0) {
    run()
    return
  }

  const id = setTimeout(run, delay)
  return () => clearTimeout(id)
}, [autoRefreshMinutes, lastRefreshed])

Also stabilize inputs at callsites with useMemo for vehicleNames and preferredParams so callback churn is reduced.

Tradeoff:

• Ref+effect scheduling is slightly more code, but more reliable.
• setTimeout is efficient/precise for “next run” scheduling.
• setInterval is simpler but can drift and do unnecessary work.

If helpful, I can put up a small follow-up PR with these fixes directly.